The invention relates to performance management of Java virtual machines and, in particular, to memory overload management of Java virtual machines in Web application sever systems.
In a Web application sever system consisted of Java virtual machines (JVMs), JVMs are used as servers that have the function of the server machine. The server function of a JVM is implemented with instances of the web application server that are deployed on the JVM. Features of the so-called grid that consists of multiple JVMs include scalability and fault tolerance.
JVM's server functions include processing of sessions initiated by the client. The client-initiated sessions are routed, through a proxy, to one or more JVMs in the web application server system. The Web application server instance handles the sessions by executing the Java servlet deployed on the JVM. Specifically, the JVM receives a request from the client, handles the request and returns a response to the client. Examples of the client's request are HTTP(Hypertext Transport Protocol) request, SIP(Session Initiation Protocol) request, etc.
Session data are stored in a web application server system. Generally, session data are divided into different data blocks (also referred to as “shard”). A shard that is active is called “primary shard”, and the replica of a primary shard is called “replica shard”. For availability purpose, the primary shard and its corresponding replica shard must not be stored in the same JVM or the JVMs that share the same physical machine.
When a JVM of the web application server system stops operation due to a failure, for example, the primary shard and the replica shard stored on the JVM will become unusable. In order to maintain the continuity of the client session in connection with the primary shard on the failed JVM, the primary shard corresponded replica shard stored on other JVM will become primary shard. At this time, shard replacement shall be carried out. In other words, on the one hand, the replication (aka, replica shard) of the newly generated primary shard shall be stored to a JVM that is different from the JVM on which the primary shard resides. On the other hand, the replica shard formerly stored on the failed JVM shall be moved to other JVM. And shard replacement may also be carried out when there is a new JVM being added to the web application server system. To conduct shard replacement, it is needed to use memory space on another JVM. If the use of the memory exceeds the maximal space that the JVM may provide, memory overload will occur in the JVM which seriously influence the performance of the JVM.